One, two. Is this on? Holy crap, this is a big room. Oh, man. I'm following Will Wright, eh? What a great position to be in.

So I guess we'll wait for a couple of minutes just as a few more stragglers come in. It's my eternal fear that Will will actually show up in here That would be embarrassing. Okay. People taking pictures, that's weird. So this lecture is about making The Sims 2. It's about how we made The Sims 2, the tool pipeline, how we define an object, how we build them, and a look at the tools actually that's built within Sims 2.

Okay, for some reason. So who am I? I'm Jake Simpson. I was the lead simulation engineer on Sims 2 for three and a bit years. I'm currently working on a top secret, super secret project that no one would ever guess in a million years. Yeah, right.

I don't think it'll be a surprise to anybody in this room. My email is here and my website, which at the moment is down, but never mind. So the talk is structured in this obvious way. We're going to talk about what actually defines a Sims object, because I use the word object interchangeably. Some of the time it means a model, some of the time it means a game object. We'll talk about the process of how we build an object, how we define it and how we build it.

We'll look at the tools that we use in order to build the objects inside of it. And we'll have a chat at the end about the scripting system and about possible different approaches. That was the bit I really wanted to push on and that was the reason they actually let me speak on this subject, because I had to talk about that. There are a few thank yous I really need to do before I go too far. The entire object engineering team on Sims 2. Object engineering is a Maxis coin term, and it's for engineers who aren't really engineers.

They have programming skills, but they're not writing C++. Some people would call them scripters, like people making first person shooters would often call them scripters, but they're not really that, they're more than that. They are the people who coordinate animations and put them together. They're the people who put sounds in. They're the people who write the scripts and make the game actually happen. All of the rest of the engineering team on Sims 2 just made an engine.

We didn't make a game. It was the object engineering team that actually made the game. There are a few other people I need to thank. Patrick Barrett, Jamie Dombos, Eric Bowman and Don Hopkins. And the reason I need to thank them is that what I'm going to show you today is actually built upon technology that these guys built for Sims 1. Sims 2 was an iterative project.

We built completely on top of the technology that was already there and extended it and changed it and refactored it when we needed to. But these guys wrote code 10 years ago that's still being used today, and I think that's a testament to how good they really are. And of course, the last person I have to thank is Will Wright, because without him, I wouldn't have a job. So, a definition of a Sims object. I wrote the slides out because the idea was that you could take the slides away and get most of the information out of them, but I'm going to go through it anyway. An object is a collection of data that has an executable thread within it that, when placed in a lot, will run code by default and be selectable by Sims autonomously and the player.

Say that three times after you've been drinking the night before. I'll tell you, that's hard. So, what that means is an object is basically just an abstract collection of information. Information that goes up to make an object. It contains stuff like localized string text, executable scripts, common definition metadata, i. e.

data that all objects will share, the same kind of stuff. Animation lists, what animations are we using. Routing information, how do I get from point A to point B and where do I stand when I'm done routing. Advertising information. The way that Sims works is that every object has within it advertising information. And that advertising information relates directly to the motives that all the Sims have.

We have this massive function we call Find Best Action, which is how the autonomous game works. A Sim is idling, standing around, he's not doing anything. So he thinks, OK, what are my motives right now? And what's my lowest motive or what do I really need to satisfy? Is my bladder really full? Do I need to find a toilet?

And then he queries all of the objects that are immediately around him to see who can satisfy that particular motive. I need to find something that's going to satisfy my comfort motive. And there are several different things in that world that will advertise to that. And that's what, when I talk about advertising information, that's contained within each object. Interaction definitions. If you've played the Sims, you know what the pie menu that comes up when you click on an object.

Those are classified as interactions. And we define those within the objects too. An object may contain model information or may not. And I'll talk about that in a minute. Some objects are physical, like a car, a toilet. An object with a model that you can see in the world.

And some objects aren't. Some objects are just instantiated and just exist. They do things like handling the weather, time of day, the visitor generator, the little bit of code that actually generates people who come to your door and knock on your door and want to talk to you. Those objects are instantiated but you'll never see them. They're never actually a model in the world. Objects can be multi-tile.

More than one game object makes up one visible object. And what that is, is that the Sims 1 was based around a tile-based world. We had little tiles and they're about a meter square. Now if you have a chair that three people can sit on, that's actually three tiles, not one. So what we actually did was instead of making one object that was three tiles, we made three objects and linked them together. And that has an advantage because each individual part of that chair is doing its own thinking.

Is someone sitting in it? Is someone not? So when you're looking for someone to sit down, you're actually querying all three parts of a chair rather than just one. There's a bit of overhead there in the number of objects that get generated on the fly, but it's generally worked out as a good approach for us. The object usage, you place it on the lot and the game engine automatically runs an initialization script and then we'll run a main script on it, a main thread on it. I'll show you some of those scripts later, but basically the idea is you can generate an object, plop it in the lot and from that moment onwards the game will pick it up and understand exactly what it needs to do through all the information the object engineers have placed within it.

All objects have advertising data in them. We talked about that. That's actually imported from an Excel spreadsheet because it was the easiest way to try and balance these things. Balancing and tuning of the Sims is a real nightmare. I'm sure you can imagine trying to balance all the emergence that's in there is quite heavy duty. So we tried to do it externally with other tools in order to make the balancing a little easier.

So we talked about what the advertising data really means. Basically the idea of an object is it's supposed to encapsulate everything that's necessary for it to run in the game. You're supposed to be able to just take one object file, plop it into a directory and that's all you need and from that point onwards you can use that object in the game. It didn't really work out that way, that was the original idea, but we didn't end up containing certain things like textures, animations and sounds and the problem was that we ended up with far too much duplication. There was far too much stuff that wasn't specific to one object and so at the end of the day we had to split it out and put things elsewhere. Some information is contained within the object and some of it is split out.

Most of it is contained within the object though. So the process of building an object, it takes anywhere from a month to maybe two months or maybe even just a week to build an object. The way it starts out is the game designers are looking at the game and they say OK, we need a new object that will satisfy the comfort motive or the fun motive. There's a lot of objects that satisfy that. And they say down, well what kind of object should we have, what's going to be easy to do, what's going to be easy to model, what's going to be fun, what's going to be cool and have different things. So they basically spec out what they want to do, like a dartboard or a kickbox, kickbag or something like that.

And then they sit down and say OK, what are the rules of the object? Can we break it? Does it need repair? Can it be stolen? Can it be carried? There's a lot of rules that come with objects, each specific object in The Sims 2.

And so they sit down and design exactly what's possible with that object and what isn't and what they really want it to do. And then there's a second meeting after that where we include some technical people. And the technical people look at their design and go, yeah, we aren't going to be able to do that, that's not going to happen. Or at least we try not to say that. So that happens next. We usually have, like I say, a lot of technical people there and we decide, OK, can we build it with the technology we already have in the game engine?

Do we need to expand the game engine in order to satisfy this? Are there other ways to do it? It's general design as you would normally do. And at that point you start making schedules and working out exactly how it's going to be built and what animations are going to be required and how it sounds are going to be required and all that kind of stuff. So then we schedule it. And the scheduling of the model always comes first.

We always build the model. And if we're building a new class of object, like a new chair for instance, what we tend to do is build a template model. And the template model is basically a model that has polygons but no textures in it. And it's the basis that you will use to build all other objects of that class. We actually contain our routing information for an object inside of the model itself. The idea is that with a chair, there is an extra bone that sits in the front of the chair that sticks out.

Nothing's attached to it, but it's just a bone. And that bone is actually where sims go to when they want to go and sit in a chair. They walk to that specific bone. And then we know where the sim is relative to the chair. So now we can generate animations where the sim turns around and sits down. And we always know that that sim will be in the correct place relative to the chair.

And it's all contained within the model itself. It's actually contained within the template. And then we take that template and actually build real models from it. And then we all know that all those models share the same positional information within it. Then we get the animation that comes in. So we have a model now.

Now we have animation that comes. And animation tends to get actually produced at the same time that the object engineer is starting to script the object. And the reason for that is because there's always to and fro between the object engineer and the animator. The animator makes his stuff in Maya. He checks it out and the game looks okay. But then we actually try and put it all together as a montage of animations one after the other.

We find that one of them is too long or one of them is too short. Or we need an extra loop here or whatever. So it's a backwards and forwards thing. So animation is occurring whilst the scripting is occurring. And the two go backwards and forwards. Generally, animators and object engineers are paired at that time for that specific object.

We don't do sound. We do sound as our last pass. And the reason that we do sound as our last pass is simply because they are locked to animations. If you have two sims that are interacting with each other, they need to have vox that actually goes for the same amount of time that they are animating. Otherwise it looks really weird. One of the biggest problems we actually have with sound in Sims 2 is the fact that we can speed Sims 2 up.

You have different speeds. And the sound itself doesn't speed up. And it's a bit of a problem. But generally we just sort of hope for the best and cross our fingers. I'm sure a lot of people in here have done that in the past. Generally, like I said, we have one scripting engineer, usually one or two animators, a modeler and a texture artist per object.

We may also have an effects generator as well. We have a specific class of engineer who builds effects for us. And they get added in at pretty much the last pass as well. We will continue to script objects right up until we ship. And sometimes past. Basically, we are tweaking everything right up until the day we go.

And it is a source of intense amusement for the object engineers that they are required to keep changing things every five minutes. So our objects and tools pipeline. How do we actually get an object into the game? We've decided what it's going to be. We've looked at the technical requirements for it. And we've decided we can do it.

And we've scheduled the time. Now, how do we actually do it? Well, we have an all-in-one tool that's a DOS-based tool called Godisco that builds all of our visual information. We basically take an output from Maya. We plug it through Godisco. And it comes out as game-ready information.

It's a one process. And it's really quick and very easy. And animators and object modelers can do it themselves at their desk. It's also tied into our Perforce check-in. So whenever you check the raw asset in for a new model, it automatically goes through that tool pipeline and gets checked into Perforce as well. For actually building the objects, we use the Edith tool.

And I'm going to show you the Edith tool in a minute. For the tuning and the neighborhoods and lot building, we actually import most of that stuff from Excel spreadsheets. It's just the easiest and simplest way of actually representing the data. We have a couple of absolute Excel whizzes on staff. And they've actually gone in and completely echoed some of the simulation that Sims 2 does inside of an Excel spreadsheet, which is pretty amazing when you actually look at it. But they can then tweak their data really, really quickly and then just press one button and it's in the game immediately.

We have various viewing tools and preview tools and all the rest of it. Again, they're all pretty much homegrown. Some are in C Sharp, some are in MFC. Some of them actually use the game engine as an independent module for rendering, so we're getting accurate preview of exactly what the real game is going to look like. And some of them actually use managed C from within the game itself. That really worked out well for us, by the way.

The interfacing of . NET and the game engine was really, really powerful. We were able to do some quite effective tools with that. So, the Edith Editor is the big do-it-all tool I'm going to show you in a second. It's MFC and it's a separate DLL that we can drop in to a shipping build and have the debugger immediately there. It was originally built for Sims 1.

It actually was originally built on the Mac. I'm not sure that many people know this, but the original Sims game was called Dollhouse and it was originally on the Mac. In fact, we still have builds of it at Maxis and I keep trying to get them to put out a little demo to show exactly what it was. But originally, like I say, it was built on the Mac and then they used the porting tool to port it across to MFC and it generated some unbelievably bad code. Oh, it was so awful. I spent six weeks going through it trying to figure out why it just didn't work.

So, the early version of this, the Sims 1 version of this, is actually also used within all our console projects that we do using the Sims. Busting Out, I can't remember the other one, The Herbs and all the rest of it, they all use the same Edith front end. They're using slightly different iterations of it and usually slightly different versions of it, but we have commonality across products which means that object engineers from Sims 2 can go to a console project and be immediately effective. I mean, they're working in a slightly different environment. It's like, if you think about it this way, it's like all the different strands of BASIC we used to have. BASIC is simply If-Then-Else and the rest of it is just syntax and it's the same kind of thing for Edith.

All the projects use the same thing and we all use the same front end. The Edith editor is completely in-game and that has a lot of implications, some of which I'll show you. And scripts are changed in real time. They're not compiled or anything like that. They're parsed in real time, which means that we can put a breakpoint, change scripts around, and run the game as we're editing. And that is incredibly powerful for fast iteration.

And that, I think, right there, is the principal reason that EA manages to pump out those expansion packs with such astonishing regularity. It's because of the fast iteration time we can build these objects in. Debugging is also done in real time. We have code breakpoints, data breakpoints, edit and continue of scripting. We have automatic saving of changes. Anytime you make any change in any script, it automatically gets saved for you, which is really nice, too.

We even have our Perforce integration built into the tool, too, so that we can check out and then directly from within the game, which is another. . . It's just one step that's removed from the object engineering pipeline. All text is entered via Edith. All text is localized externally.

But what we do is we put it all in in English first. And then we have a separate tool that will extract all the English stuff and automatically filter in the localized versions. And we actually contain all of the localized versions within The Sims at any one given time. We actually have to strip some of those out when we do SKUs for different languages, for rules with France and stuff like that. But then that's French people, so what do you expect? Sorry, I shouldn't have said that.

I'm British. Okay. So, let's see what we've been talking about here, then. All right. This is The Sims right here running. It's a level I'm sure everyone has seen.

And this is the Edith editor. It doesn't look like much here, but it all revolves around the object browser. The object browser here, this here, is all of our objects. Now, it's not actually all of the objects in the game. And the reason for this is that we actually have a cut-down version of Edith that we've released to a couple of universities. I think University of California and Carnegie Mellon have a video games track, and they're actually using Edith and Sims 2 as part of their education of real-world tools.

So, I'm actually using what we gave to the Carnegie Mellon people. So, here what we've got here is all of the objects that you have selectable. And I can open up, just by double-clicking on them, I can open up that object. And this is now showing me all the details within that object that I need to know. These here are scripts that we use. And you can see that there are interactions within here that actually directly tie to what interactions you'd actually have on a chair.

We have other information I can see. These are the strings that I was talking about. Now, the interesting thing here is that these strings, some of them are localized and some of them are not. We use real strings for animation names. We don't use IDs and stuff like that. We use a real name.

And so, I can show you, these are the strings, the names for each of the animations that we use. And I'll show you examples of how they're used. And our string package allows us to also put a description next to it. And within that description, we can say, these strings are to be localized and these strings are not. And our external tool will realize this, look at these and say, I don't have to worry about these. It's kind of nice that it's all integrated in one place.

And you can see here that we have all the different languages ready to go. If I go to Dutch, it's just going to give me English because they're all English at this point. We have things called constants. And the idea is that these are variables that are externally available. We can actually import these from either a database, or however we wish to, really easily. And these are the variables that make the game tuning happen.

At the moment, you can see here, we've got a comfort inc and a comfort max. This is basically saying that every tick you're sitting on a chair, you're going to get 50 added to your motive for comfort. But it will max out when you reach 100. And you will have a maximum of 10 loops and you'll have 10 seconds worth of sitting down that you're ever going to get. And these are the variables that the object engineers put in when they're building the scripts. They're exposed to tuning.

And tuning knows what these variables are and can play with them in order to make a chair more or less useful, and more or less likely that the sim is going to choose it to use. Alright, so let's look at some of the trees. Let's look at this. Alright, this is how our trees look. It's a visual scripting system here. And you can see it scrolls around.

It's a basic if-then structure, really, when you look at it. You've got some that are if-then and then some that are not, that just go through. These are independent threads that run by themselves. It's re-entrant. And we have certain primitives in here. They're called primitives.

That we'll use. I'm trying to find a routing one. Oops. Yeah, yeah, yeah, go away. Here we go. So, here's our routing primitive right here that allows us to actually say, we want to route to this object.

The sim is going to come in here and route to this object. And then we have another node that says, is this object actually in use? If we route to it and somebody's already sitting in it, what do we do then? So we handle it. We have a snap into, which basically makes the sim a part of that object. He's now attached to that object.

So if you pick that object up and move it, the sim will go with it. Here's an animation primitive here that says, okay, we need to do some animation. It's saying, run the adult animation on here. It gets a bit complicated with all the options you can possibly have. But this is basically saying, run an animation. And what happens when the thread is running is we get to this point, this animation primitive, and we sit in here until such time as the animation is complete.

So basically, the thread comes in. He starts to animate. Immediately, it comes out of the script and it goes on to the next object to process. And every frame, this thread will come in, look at this primitive and say, am I done yet, am I done yet, am I done yet? And here we've got at the bottom, where we're actually starting to modify the motives. We've sat down in the chair now, so now it's time for us to actually start upgrading the motives.

So this is an example tree. And what's really interesting here is that you can call recursively. It's a fully stacked system. You can go in and out and do whatever you want to do. You can pass variables backwards and forwards. Each one of these primitives itself, you actually edit it by double-clicking on it quite easily.

And here's all the primitive information within it that you can set up. What's even cooler, though, is the fact that you can just copy this and put it over here so you can make scripts really quickly. You make small, modular scripts and just copy them around really quickly. I mean, we do run into cut-and-paste problems there, but everyone has that. So that's how our trees look. There's some other stuff I wanted to show you.

That's right. The chair. We talked about definition, object definition stuff. And this here is telling you all of the information that every object will share. This is information that every object has. There's like wall flags here, wall placement flags.

What that means is, when I try and put an object into the world, am I going to allow it to stand next to a wall? Am I not? Am I going to allow it to stand on floor that's not flat? That's kind of information that we're defining in here that's the same for every object. And there's a lot of it, actually, funnily enough, now I look at it. The interaction is.

. . This is the definition of the interactions. What we have over here, what I'm showing you here, are the trees. These are the actual scripts that get run. But what we need is a method where we can actually define what the interaction is and say, this is the interaction I want to show up on a pie menu and I want to attach advertising information to it so that the sim can do this autonomously by itself.

And this is the information that we have that actually defines each interaction. So what we've got here, the first one is an interaction. It's called sit times. And there's another one called sit looping. And another one called. .

. You can see up here the name. This is what actually appears in the pie menu. And there's information within here that say, this interaction is available to visitors. It's available to children. But it's not available to toddlers because toddlers can't sit in chairs.

Over here, this is the motive information. This is the advertising information. What we're saying here is that. . . Wow, this doesn't actually.

. . That's interesting. It doesn't actually have any advertising information within it. That's just a bit strange. Usually what we have is, these are each of the motives and it's saying, I'm going to give you X percentage of motive increase.

And that's the advertising information I was talking about earlier that the game uses to determine which object it wants to actually interact with. There's a lot of other information within here that's probably not relevant right now. But there's an awful lot of stuff within here. An interesting thing we've got here is, if you look down here, there's actually two scripts that are being called here. There's interaction sit test and interaction sit time. We have a test tree that we can run, a test script that we can run, before we allow any object to be used.

And it's a real quick way of saying, well, you know, you aren't old enough to use this object or this object is already in use, so I'm not going to allow you to use it. It's a small tree that we use and it's very powerful because it's like a two-stage bit of processing. You're doing a little bit of pre-processing to determine whether that interaction is actually available and then if it is available and selected, you can go in and run the main script. I'll show you what the test one looks like. Basically, the test tree here, all it's saying is, is this object already in use? What happens is, when those interactions come up, you click on an object, it'll run this tree first to see whether that interaction is actually viable and if it's not, then it won't display it.

Okay. Okay. Yeah, that's pretty much it. You can see here we've got Perforce integration and all that good stuff. I'm going to show you what is now a social interaction. Social interactions are the ability of one sim to sync with another sim to do something.

When you're interacting with a chair, a chair just sits there. It's not doing anything by itself. You don't need to be very sophisticated in how you actually get one sim to use it. It's just sitting there. But when one sim is talking to another sim, we run into issues of timing and synchronicity and stuff like that. Because it's a multi-threaded environment, we're basically looking at race conditions is what we're looking at.

So, our solution to that is not actually to have one sim talking to another. It's just not really viable. What we do is we create a third object and it's an object with no model. But what it acts as is a manager that manages the other two sims. So, those two sims are not actually talking to each other at all. They are being dictated to by a higher level object.

In this case, it's called a social manager. So, the social manager, let's say I want to have an interaction with Chris Butcher down here. Oh, he's now getting worried now. I have an interaction down here. We generate a third object that will now sit, imagine it sitting over the top of us, hovering over us, and it will now dictate to me, you will go over and stand in front of him and it will dictate to him, stand there and wait, and then it will say to us, it's okay, now both of you do this. So, instead of trying to sync the two objects together, we just let our third object do it.

It works very well for us, although we do tend to end up with a lot of these lying around, these social interaction objects. I'm not even sure what this is. But again, interaction person A, it's basically this script is saying to person A, this is what you're going to do and here's your animations and this is what we're going to do, blah, blah, blah. And then, here's the interaction for person B and it's almost the same, but it knows at the beginning that they're going to be synced up. Okay. There's something else I was going to show you.

I'm trying to remember what it was. Oh yes, I wanted to show you some of the debugging stuff. So, within these trees, that you were looking at, you can put a breakpoint on these objects, here. And it will actually, as we run the game, it will actually stop here and bring up this debugger in all its glory and show me a lot of information. In fact, I think what I'm going to do is actually try and generate one of these objects. Hmm, maybe not.

Yeah, unfortunately, this is the debug version of it that we give out and it is missing certain information within it, certain abilities within it. The idea is that I can generate, within these objects, I can generate breakpoints that will allow me to stop the game and as it's running, it will pause the game, bring up the debugger with that tree and I can actually debug on my way through it. It's extremely powerful. Our object engineers would be lost without it. So, Hey, give me my mouse back. Thank you.

Okay, it's all the way through. So, I'm going to talk about the actual scripting language that you saw some primitives for there. It's an interesting language because it's homegrown. It's real-time parsed or interpreted however you want to put it. It's not compiled. It's a binary format.

We store it out as a binary format. We don't store it out as an XML file and we don't store it out as text. The reason being that we don't want to parse it when it's being loaded. We want it to be loaded instantly and just run. So, we do store it as a binary format and the other reason that we store it as a binary format is really to try and stop reverse engineering. I'm sure you've all heard about the Sims hacking that's been going on and it's quite unbelievable what these guys managed to actually work out for themselves.

We didn't think they'd be able to. The primitives themselves that you saw there are all fixed sizes in length. The amount of information that can be contained within any given primitive is fixed. That was a mistake on my part and I shouldn't have done that but it worked out in the end. The problem is that you end up wasting a lot of space. Well, we're on a PC so we really don't care but when it comes to console games we really should be taking more attention to that.

The semantics language is all relative. We specifically, within the scripting language, do not allow mathematical, complex mathematical functions. We don't actually even give the object engineer when he's coding real world positions for anything. We don't say to him oh, this object is at position X, Y and Z and do some math to work out how you want to get there. We don't do any of that and we do that expressly to avoid really heavy overheads of parsed math functions. We generally build the scripting system such that we look at what object engineers are trying to do and if they've built some amazingly complex script that's trying to work out some trigonometry, I will come along, look at that and go you know what, I'll give you a new primitive.

I will do all that work for you in C++ because it's much, much faster than you trying to do it in scripts. So we basically avoid a lot of the real time sinks and CPU abuses by just not allowing people to do it. The interesting implication there though is that because it's all relative, there's a lot of information that is missing. Things you can't really do. We can't do camera work and stuff like that within a script because we don't know where the camera is relative to objects. The way we really handle it is basically we would say to the system please route me to this object and in front of it please.

And if you remember I mentioned how the object contains within it information bones that say this is where I want to route to. So the in-game engine knows where it's trying to go but the scripting system doesn't know and doesn't care. It's an interesting point of view. It's like the deliberate dumbing down of a language but it actually works for us just to avoid some really bad CPU overhead. That's not to say that we can't write scripts that are really bad news though. The scripts themselves are directly callable from hooks within code as well.

We don't have to go through that interaction system that I was showing you. We can actually just call scripts directly. We try not to do that because we want to have a differentiation between the scripting system and the C++ engine but we do tend to short circuit it an awful lot because it's just quicker and easier to do it that way. I talked about it being multi-threaded. Each object has its own thread. It's linear but it is re-entrant and the beauty of this is that it actually will work very well on a multi-celled environment although the information that's being interrogated by scripts tends to be random access which is a bit of a problem.

We have yielding primitives like I said that basically they wait until their functionality is complete. If I ask a sim to route from point A to point B the engine will know and will continue the route and move him along until such time that it gets to where it's going and then it returns control back to the thread again. Each thread is stack-based. You can pass data to functions just like you would call functionality and call other functions even in different objects if you want to. One of the nice things about the scripting system being built by us is the fact that we have an awful lot of internal error checking. When a script crashes we can detect that really easily.

When a script tries to call a primitive that isn't going to work I want to route over there but somebody's built a brick wall in my way. We can detect that very, very quickly and we can deal with it. We can also deal with situations where a sim needs to be reset. Sometimes there are bugs in the code and sometimes in the semantics scripts and we have to recover from that. And we have the ability to detect that and reset the sim completely. We just basically pick him up and dump him in the middle of the lot basically and reset all of his attributes to the attributes they were when he entered the lot initially.

It's really nice because we can detect this and we can actually put breakpoints within the code that say I'm going to have to reset you now because there's a bug right here. So, the pros of doing this of the EDIF and the semantics language is the fact that it's real time. It's not easily reversed engineered. Well, we didn't think it was easily reversed engineered but apparently it is. Sad. All of the functionality is in one place as you saw with the tool.

It's all there. It's all in one place. It's one DLL and you can just drop it into any build and look at what's going on. It's actually because we spent so much time on it it's almost a release quality tool. Like I said we released it to a couple of universities and I think Ben Gordon at EA was the one who masterminded that. So, students can actually generate objects for themselves and see what a real world application is like.

It has many profiling and ease of use features. I talked about the fact that we put Perforce integration in there. It's one of the primary tools that as the game runs will look at what primitives are being called what objects are expensive how many calls there were per frame and stuff like that. Because we generate the primitives that this language can use we have real limits on CPU intensive scripting operations. Like I said generally I tend to look at the scripts see where they're doing a lot of iterative work and then I pick that up and make that a separate primitive for the object engineers to use and everything goes faster. I can do it in a day it's that fast.

It's really quite powerful. I talked about the automatic real time error checking and recovery. It is tailored for use in Sims games. Originally when it was being designed the concept was that the language could be used by any game anywhere. They were talking about using it for Sim City at one point. As time has gone on we've tended to get a little more specific particularly with things like animation primitives it's very Sims oriented and very Sims specific but a lot of this is just generic stuff that we could probably pick this up and dump it into another engine very very quickly.

So the cons of it the bad sides of it is you have to be running the game in order to edit a script because they're not text because they're binary if the game doesn't work you can't edit a script and that's quite frustrating at times if anything is wrong with the executable. We need an awful lot of empirical knowledge. What I'm showing you there is very powerful but you really have to know how to use it. You have to know what all of those definitions do. You have to know what the animation features actually mean. We do have quite a lot of documentation for it not that it's particularly up to date but we do our best.

It is it's a long ramp up time for object engineers to be productive immediately. Generally object engineers take about a month or so before they get to the point where they're actually building objects by themselves because of the fact that you just you know they're complicated and aren't resizable. Yeah I showed you one primitive there the animation primitive I like to refer to that as my NASA control primitive and I'm convinced you can actually land the space shuttle with it. It's got so many bits and knobs on it. This is not a transferable skill set. It is within Maxis because we use all over the place our internal scripting language but realistically you can't hire someone to be able to do this immediately.

You can't have somebody who comes in and also the time that they spend working on this project they're not getting experience in something they can take to another job. Not that of course anyone ever wants to leave EA of course but if they did it's not a transferable skill set. The overhead of parsing is it's not insignificant. Any embedded language has overhead of parsing and we have the same issues that Lua does and all the rest of them so there is overhead and that's why we try and restrict some of the things that engineers can do like expensive trigonometry. And the other thing about this is that it's not that easily scalable. Realistically on Sims 2 we can probably get on a base machine about 10 sims simulating at 30 frames per second.

If we wanted to put 100 sims in there there's just no way we'd do it because it would grind to a halt because all the script access is just our biggest overhead. That really is more of a C++ problem that's just C++ overhead and the fact that we're using legacy code from 10 years ago is not quite right but it works so why do it? It isn't really a scalable solution and that's a bit of a problem but we'll deal with it. So I want to talk about the scripting approach about using something like an embedded scripting system or taking an off the shelf scripting system like Lua or Python and using that instead. We've got this parsed and interpreted VS compiled issue that I mentioned earlier on about the fact that if you're running interpreted interpreted is required to do edit and continue which is what is really necessary for rapid development. You don't want to have to go away and recompile you know edit something in a text file recompile and then rerun the game in order to see implications or whatever the changes you've made.

Parsing is definitely faster to develop with but it does have runtime overheads. It does have the advantage of being homegrown and therefore game specific and homegrown editors factor into this. If you're going to run a text text files then you've got a ton of different editing suites you can use that are really good to do that. It doesn't have to be notepad. If you wanted to go with Lua or Python you do have more overhead. The API is a bit harder as well because it's trying to be all things to all people.

It's not specific to what your game is doing and it's because it is so open because you have trigonometry functions all the math functions it's much harder to detect and deal with bad practices. Again though that's more about tools than anything else I think. But it is a transferable skill set. You can hire people that know Lua and if you train somebody to use Lua it's something they can put on their resume and take elsewhere. Your potential for mod development is much greater too. And of course Lua just works.

We already know it works. You can put it into your engine tomorrow and start developing with it immediately which is really powerful. Either way whatever scripting system you decide to use you need good debuggers. I'm quite convinced that homegrown debuggers is the way to go because you need to have a debugger that's specific for what your game is trying to do. It's no good having all the profiling tools in the world if you're not using the features that the profiling is giving you. The other thing I was going to say was we do a lot of this in Sims.

We access game data directly. The game data is serialized by the engine internally and stored within the game engine. The game engine is talking to those variables directly. If you use something like Lua, Lua is designed to be a separate entity. It's designed to have its own thread and its own stack and all the rest of it and you have the right functionality that will allow it to talk to the game engine. You can't just look at Lua variables inside of a debugger like MS Dev because it's all stack based.

It's all stored away in such a way that you can't really get to it very easily which is a bit of a problem because if you are detecting a bug, you need to reset all that data and if it's not directly, you can't directly get to it, it's really kind of hard to actually reset the data correctly. So we tend to like, we want to store all of our data inside of the main game engine rather than inside of Lua. There's some interesting things that we have with our object construction. We actually have a hierarchical construction system, very much like C++ inheritance, whereby an object may actually have three different files that we relate to it. They're called global, semi-global and private. The idea is that something like a chair has shared functionality.

A lot of, we may have ten different chairs in the game but they're all using exactly the same functionality. So what we do is we put all the scripting in a high level, a high level file that all of these objects will reference back to. So all of the sit down and stand up functionality and scripting is in one place. And then we have individual instances of each specific type of chair. And then we have individual instances of each specific type of chair that all reference back to that original script. And that has a couple of implications for us.

The first is that should we need to release a patch, if we need to release a patch, all we need to do is upgrade the global file that has all the scripting in it and release that. And all of a sudden all of the objects that are in the game will actually reflect that new scripting work. Which is quite powerful because it actually really makes our downloads much much smaller. Semi-global files, yeah we talked about that for object files. They contain, so basically your semi-global or your global files contain information that's common. And then you get down to a specific object file and you say okay this model is different from that model.

Or this one has extra animations that we want to do that over and above what all of the other chairs would do. We have one special chair that has arm rests. So we want to be able to put our arms on the arm rests. But that's only in that specific chair object. But it still shares all the rest of the scripting from all the other chairs use. The exporting and importing and tuning constants for outside modification is an interesting oddity in so far as we expose it all through Excel.

We can actually generate Excel spreadsheets from within the game of all of the information that we've made available and public to the game designers. So at any point they can sit down, press a button in the game, get this massive spreadsheet and then they can start modifying all the variables within it and then just press another button and it imports it right back again. We do actually have inside of the game tools that enable people to actually modify these tuning constants if they want to. But we don't tend to use it very much because it's object oriented which means you have to do it for each specific object. You have to bring up an object, look at those variables, change them, save them, put them away, bring up the next object. Whereas with an Excel spreadsheet you just press one button and they're all set.

We found that the profiling and debugging tools become more important as you go on. Profiling is just everything and the debugging tools is just I can't tell you how important they are to us. When you're dealing with a scripted threading system of this nature, being able to see what's going on in it at any given time at a macro level or a micro level of being able to go down to the specific primitives and seeing what's going on is really important. We have all sorts of logging systems in there that will log the game so we can leave it running overnight and come in in the morning and look at the log that we've got of exactly what happened and why. Why did these decisions get made? Why did this work?

Why did this fail? That kind of stuff. So, right, I guess it's time for some questions if anyone has any. I can't see bugger all because there's a big old light up there but never mind. I tried to compress an awful lot in here and I apologize for that. There's just so much that I could talk about here that's really top level stuff.

So, any questions? Yeah. That's a really interesting question because I'm actually in that position right now. So, that's an interesting question. We're actually exploring using Lua right now as an alternative to this. Trying to figure out whether or not it's better or worse and we're definitely finding the pros and cons.

I mean, I was listing some of the pros and cons. I really like this, the system that we have but I think that it's limited in terms of what we can do with it. It's limited, it's not scalable and I think I probably would go with an off-the-shelf scripting solution next time around. But I would also heavily modify it so that I can get into it much easier than the average Lua interpreter gives you. Jamie? What kind of background would you need to become an object engineer?

That's a really good question too. The question is what kind of background would you have to become an object engineer? They're incredibly hard to hire because we need animation and say that's not right or this needs to be faster and this needs to be slower. We need game designers because that's where a lot of the magic of The Sims comes from is the object engineers adding stuff as they go along. Oh, wouldn't it be great if we farted at this precise moment? That kind of stuff.

That's where a lot of the humor comes from and it's very hard to actually hire people who have that view of the game. It's really hard and we go through a lot of object engineers. Heather? In Sims 1 they didn't have want and fear in the code. That's right, yeah. Do you have to add that to the game?

No, there's a separate thing. In Sims 2 we have this wants and fears functionality which I didn't really talk about. Wants and fears is an overlay over the top of your motives. What it basically does is it allows you to have aspirations to be rich so let's go away and these are the things you need to do in order for him to become rich. That was a completely separate thread that we wrote . net tools for.

The reason I didn't actually cover it here is it's not part of the simulator. I know that sounds like a strange thing to say but it isn't because Sims cannot autonomously do the stuff in their wants and fears. Any other questions? Yeah? So how did you go about handling more complicated multi-tier processes? Such as I want to make sure he has to go prepare food, create an object.

Right, right. Those are the things that you need to do in order for him to become rich. Right, right. Those are really long scripts. They're very long and really complicated. We actually had a guy dedicated to doing that.

Food preparation is actually the longest and hardest thing because it's most interruptible. You can stop. I'm halfway through preparing this and now all of a sudden I need to go to the kitchen and that's what he does. And then there's a second interaction immediately after that that says I'm going to chop this food up. And what we do is we advertise it falsely so it basically is going to be more likely to do that. Even though we're not actually going to do it.

To be honest. Any other questions? The question is where is the bulk of our overhead? And it is absolutely the two biggest spikes that we have in Sims 2 is the find best action, which is the autonomy deciding what he's going to do next and the planning of the routing. And the decision maker. And I had to do all sorts of stuff to try and make it faster.

The biggest problem comes in that it's a logarithmic problem because the more objects you add, the more interactions it has to check to see do I want to do this, do I want to do this. And it's running that test tree on almost every interaction on every object in a lot. So an experiment where we check the top ten potential interactions, that kind of thing. We put all sorts of stuff. In fact, we did a little bit of load balancing as well where we look at the number of objects in the lot and we may do more or we may do less. We look at the number of Sims, we look at the number of Sims, we look at the number of Sims, we look at the number of Sims.

Any more questions? Yeah, over there? How long did you spend developing the debugger and all that stuff? Oh, I didn't spend any time because I just picked it up from Sims 1. But realistically I probably spent about a year. Sorry, the question was how long did you spend developing the debugger and all that stuff?

I spent a year basically working with object engineers looking at their tool flow and working out where all their blockages were. I actually spent some time as an object engineer on one of the Sims expansion packs in order to use these tools properly so that as a developer I could use the tools I was doing to make them faster. So we spent about two years or so getting it to this point. The initial implementation of Sims 1 was seven years. But you have to understand that it was a pet project. It wasn't a let's produce this.

It was Will basically farting around and having a lot of fun with this thing now. It was a long, long project. Sims 2 took probably about three and a half to four years from start to finish. Yeah. Right. That's a really good question.

The question is would we ever expose something like Edith to the public for them to make objects. I agree with you. I think we should be doing that. And Will does too. And that's principally why this functionality is being made available to universities and stuff like that. But we do have a couple of caveats.

The first is this. We don't want to do ourselves out of an awful lot of money from expansion packs. If we give these tools away then basically anyone can use them. If we allow anyone to go in there and start mucking about with scripts then you end up with objects that don't work and can conceivably crash the game. It's very protective about trying to maintain the integrity of the Sims. It's one of their flagship products and they just don't want to mess about with it.

The question is how do we make the Sims not the same? They have the motives for a start but they also have the wants and fears stuff is paramount. They also have. . . When you set up a Sim you have to set up his.

. . What's the word? The personality thing. That's the horoscope or whatever it is. You have to set up whatever.

And that actually adjusts what they're interested in doing and what they're interested in talking about. When we generate a new Sim we randomly generate their interests. Are they interested in talking about sports? Are they interested in talking about whatever it is? And then they will actually balance out towards that gender. So you can totally control that.

But when we generate them we generate some stuff randomly like some of their motive stuff. We give them personality based on horoscope. And that's the kind of thing that adjusts it. And that's the kind of behavior. But they are embedded within the actual Sims themselves. Sims are special case objects that have extra functionality.

Basically some extra variables within them. But they are basic objects at the root of everything. They're just objects just like chairs are. Any other questions? The question is we seem to have duplication of data. We have this advertising information and we have the actual scripts themselves that are actually doing the fulfillment.

It sounds like duplication but it's not. There's a difference between what advertising represents and what the object is actually going to do. We can sometimes abuse the construction chain. We artificially inflate the advertising, the potential advertising for certain stages of the food preparation menu to make sure the Sim will continue to do those interactions. What you actually get back from it and what you're promised aren't the same thing. We use that and abuse it all over the place.

The other thing about that is that the duration of time I sit on the potty is how much my bladder is relieved. If I make the Sim get up immediately then he's not getting as relieved as possible. It's not quite the same thing. Any other questions? Good. Time for beer.

All right. Thank you.

